The Linux Kernel HOWTO: Some pitfallsNext Previous Contents 


9. Some pitfalls 
9.1 make clean 
If your new kernel does really weird things after a routine kernel upgrade, 
chances are you forgot to make clean before compiling the new kernel. Symptoms 
can be anything from your system outright crashing, strange I/O problems, to 
crummy performance. Make sure you do a make dep, too. 
9.2 Huge or slow kernels 
If your kernel is sucking up a lot of memory, is too large, and/or just takes 
forever to compile even when you've got your new Quadbazillium-III/4400 working 
on it, you've probably got lots of unneeded stuff (device drivers, filesystems, 
etc) configured. If you don't use it, don't configure it, because it does take 
up memory. The most obvious symptom of kernel bloat is extreme swapping in and 
out of memory to disk; if your disk is making a lot of noise and it's not one of 
those old Fujitsu Eagles that sound like like a jet landing when turned off, 
look over your kernel configuration. 
You can find out how much memory the kernel is using by taking the total amount 
of memory in your machine and subtracting from it the amount of ``total mem'' in 
/proc/meminfo or the output of the command `free'. 
9.3 The parallel port doesn't work/my printer doesn't work 
Configuration options for PCs are: First, under the category `General Setup', 
select `Parallel port support' and `PC-style hardware'. Then under `Character 
devices', select `Parallel printer support'. 
Then there are the names. Linux 2.2 names the printer devices differently than 
previous releases. The upshot of this is that if you had an lp1 under your old 
kernel, it's probably an lp0 under your new one. Use `dmesg' or look through the 
logs in /var/log to find out. 
9.4 Kernel doesn't compile 
If it does not compile, then it is likely that a patch failed, or your source is 
somehow corrupt. Your version of gcc also might not be correct, or could also be 
corrupt (for example, the include files might be in error). Make sure that the 
symbolic links which Linus describes in the README are set up correctly. In 
general, if a standard kernel does not compile, something is seriously wrong 
with the system, and reinstallation of certain tools is probably necessary. 
In some cases, gcc can crash due to hardware problems. The error message will be 
something like ``xxx exited with signal 15'' and it will generally look very 
mysterious. I probably would not mention this, except that it happened to me 
once - I had some bad cache memory, and the compiler would occasionally barf at 
random. Try reinstalling gcc first if you experience problems. You should only 
get suspicious if your kernel compiles fine with external cache turned off, a 
reduced amount of RAM, etc. 
It tends to disturb people when it's suggested that their hardware has problems. 
Well, I'm not making this up. There is an FAQ for it -- it's at 
http://www.bitwizard.nl/sig11/. 
9.5 New version of the kernel doesn't seem to boot 
You did not run LILO, or it is not configured correctly. One thing that ``got'' 
me once was a problem in the config file; it said `boot = /dev/hda1' instead of 
`boot = /dev/hda' (This can be really annoying at first, but once you have a 
working config file, you shouldn't need to change it.). 
9.6 You forgot to run LILO, or system doesn't boot at all 
Ooops! The best thing you can do here is to boot off of a floppy disk or CDROM 
and prepare another bootable floppy (such as `make zdisk' would do). You need to 
know where your root (/) filesystem is and what type it is (e.g. second 
extended, minix). In the example below, you also need to know what filesystem 
your /usr/src/linux source tree is on, its type, and where it is normally 
mounted. 
In the following example, / is /dev/hda1, and the filesystem which holds 
/usr/src/linux is /dev/hda3, normally mounted at /usr. Both are second extended 
filesystems. The working kernel image in /usr/src/linux/arch/i386/boot is called 
bzImage. 
The idea is that if there is a functioning bzImage, it is possible to use that 
for the new floppy. Another alternative, which may or may not work better (it 
depends on the particular method in which you messed up your system) is 
discussed after the example. 
First, boot from a boot/root disk combo or rescue disk, and mount the filesystem 
which contains the working kernel image: 
    mkdir /mnt
    mount -t ext2 /dev/hda3 /mnt
If mkdir tells you that the directory already exists, just ignore it. Now, cd to 
the place where the working kernel image was. Note that 
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot
Place a formatted disk in drive ``A:'' (not your boot or root disk!), dump the 
image to the disk, and configure it for your root filesystem: 
    cd /mnt/src/linux/arch/i386/boot
    dd if=bzImage of=/dev/fd0
    rdev /dev/fd0 /dev/hda1
cd to / and unmount the normal /usr filesystem: 
    cd /
    umount /mnt
You should now be able to reboot your system as normal from this floppy. Don't 
forget to run lilo (or whatever it was that you did wrong) after the reboot! 
As mentioned above, there is another common alternative. If you happened to have 
a working kernel image in / (/vmlinuz for example), you can use that for a boot 
disk. Supposing all of the above conditions, and that my kernel image is 
/vmlinuz, just make these alterations to the example above: change /dev/hda3 to 
/dev/hda1 (the / filesystem), /mnt/src/linux to /mnt, and if=bzImage to 
if=vmlinuz. The note explaining how to derive /mnt/src/linux may be ignored. 
Using LILO with big drives (more than 1024 cylinders) can cause problems. See 
the LILO mini-HOWTO or documentation for help on that. 
9.7 It says `warning: bdflush not running' 
This can be a severe problem. Starting with a kernel release after 1.0 (around 
20 Apr 1994), a program called `update' which periodically flushes out the 
filesystem buffers, was upgraded/replaced. Get the sources to `bdflush' (you 
should find it where you got your kernel source), and install it (you probably 
want to run your system under the old kernel while doing this). It installs 
itself as `update' and after a reboot, the new kernel should no longer complain. 

9.8 I can't get my IDE/ATAPI CD-ROM drive to work 
Strangely enough, lots of people cannot get their ATAPI drives working, probably 
because there are a number of things that can go wrong. 
If your CD-ROM drive is the only device on a particular IDE interface, it must 
be jumpered as ``master'' or ``single.'' Supposedly, this is the most common 
error. 
Creative Labs (for one) has put IDE interfaces on their sound cards now. 
However, this leads to the interesting problem that while some people only have 
one interface to being with, many have two IDE interfaces built-in to their 
motherboards (at IRQ15, usually), so a common practice is to make the 
soundblaster interface a third IDE port (IRQ11, or so I'm told). 
This causes problems with linux in that versions 1.2.x don't support a third IDE 
interface (there is support in starting somewhere in the 1.3.x series but that's 
development, remember, and it doesn't auto-probe). To get around this, you have 
a few choices. 
If you have a second IDE port already, chances are that you are not using it or 
it doesn't already have two devices on it. Take the ATAPI drive off the sound 
card and put it on the second interface. You can then disable the sound card's 
interface, which saves an IRQ anyway. 
If you don't have a second interface, jumper the sound card's interface (not the 
sound card's sound part) as IRQ15, the second interface. It should work. 
9.9 It says weird things about obsolete routing requests 
Get new versions of the route program and any other programs which do route 
manipulation. /usr/include/linux/route.h (which is actually a file in 
/usr/src/linux) has changed. 
9.10 Firewalling not working in 1.2.0 
Upgrade to at least version 1.2.1. 
9.11 ``Not a compressed kernel Image file'' 
Don't use the vmlinux file created in /usr/src/linux as your boot image; 
[..]/arch/i386/boot/bzImage is the right one. 
9.12 Problems with console terminal after upgrade to 1.3.x 
Change the word dumb to linux in the console termcap entry in /etc/termcap. You 
may also have to make a terminfo entry. 
9.13 Can't seem to compile things after kernel upgrade 
The linux kernel source includes a number of include files (the things that end 
with .h) which are referenced by the standard ones in /usr/include. They are 
typically referenced like this (where xyzzy.h would be something in 
/usr/include/linux): 
    #include <linux/xyzzy.h>
Normally, there is a link called linux in /usr/include to the include/linux 
directory of your kernel source (/usr/src/linux/include/linux in the typical 
system). If this link is not there, or points to the wrong place, most things 
will not compile at all. If you decided that the kernel source was taking too 
much room on the disk and deleted it, this will obviously be a problem. Another 
way it might go wrong is with file permissions; if your root has a umask which 
doesn't allow other users to see its files by default, and you extracted the 
kernel source without the p (preserve filemodes) option, those users also won't 
be able to use the C compiler. Although you could use the chmod command to fix 
this, it is probably easier to re-extract the include files. You can do this the 
same way you did the whole source at the beginning, only with an additional 
argument: 
    blah# tar zxvpf linux.x.y.z.tar.gz linux/include
Note: ``make config'' will recreate the /usr/src/linux link if it isn't there. 
9.14 Increasing limits 
The following few example commands may be helpful to those wondering how to 
increase certain soft limits imposed by the kernel: 
echo 4096 > /proc/sys/kernel/file-max
echo 12288 > /proc/sys/kernel/inode-max
echo 300 400 500 > /proc/sys/vm/freepages


Next Previous Contents 